1. Field of the Invention
The present invention relates to a technology for supporting development of a broker program.
2. Description of the Related Art
Middleware platform technology, such as common object request broker architecture (CORBA), realizes interaction between applications described in various programming languages. A specification of the CORBA defines mechanisms for creating server applications and client applications, and operating the created applications. Thus, the server applications and the client applications need to be developed according to the specification.
FIG. 23 is a diagram for describing a method of developing applications according to CORBA. A developer designs a server application and a client application (see (1)). The developer describes interface definition information of the server application, to create an interface definition language (IDL) file (see (2)). The developer describes a source file for the server application and a source file for the client application (see (3)).
For example, the source file of the client application can be described by a method using a static invocation interface, in which a function of the server application is directly called from the client application. FIG. 24 is a diagram for describing a source file of an application according to CORBA. The developer describes initialization of an object request broker (ORB), acquisition of an object reference of a naming service, acquisition of an object reference of the server application, and calling of an operation of the server application, in this order (see (1) to (4)). The source file of the client application shown in FIG. 24 is described in a C language by the developer. However, descriptions according to CORBA are included in the source file. Although not shown, the source file of the server application described by the developer also includes descriptions according to CORBA.
Referring back to FIG. 23, the IDL file created by the developer at (2) is compiled by an IDL compiler on the server application side and on the client application side, so that programs for brokering interaction between the applications are created. Specifically, the IDL file compiled on the server application side becomes a skeleton, and the IDL file compiled on the client application side becomes a stub (see (4)). The generated skeleton is compiled and linked with the source file of the server application described by the developer at (3), so that a server application in an executable format is generated (see (5)). The generated stub is complied and linked with the source file of the client application described by the developer at (3), so that a client application in an executable format is generated (see (6)).
To develop an application according to the specification of CORBA, the developer is required to describe, at (3) in FIG. 23, the source files of the server application and the client application according to CORBA, as shown in FIG. 24. Thus, the developer needs to have knowledge on CORBA, which causes a burden on the developer.
Japanese Patent Application Laid Open No. 2003-157242 discloses a method in which the developer is not required to describe the source files of the server application or the client application according to CORBA. Instead, an interaction adaptor, which is generated from an IDL file indicating interface definition information of the applications, performs processings, makes settings, and converts data types according to the CORBA specific specification. The interaction adaptor accesses a CORBA object, which is obtained by dividing an application by each function, so that interaction is realized between applications.
There are various examples of the interaction adaptor. In an example explained in paragraph 0041 in Japanese Patent Application Laid Open No. 2003-157242, an interaction adaptor is generated for each class of the CORBA objects, corresponding to an interface in IDL, and accesses an arbitrary CORBA object. In another example explained in paragraph 0093 in Japanese Patent Application Laid Open No. 2003-157242, a single, versatile interaction adaptor accesses an arbitrary CORBA object.
In any case, the interaction adaptor needs to identify a CORBA object among plural CORBA objects. Accordingly, a naming service function is used to identify a unique CORBA object. For example, as shown in FIG. 25, an application server, which is a middleware intended to realize interaction between applications, holds an identifier of a CORBA object and object information corresponding to the identifier as the naming service function. The interaction adaptor refers to the naming service function to generate a CORBA proxy, and uses the generated CORBA proxy to access a CORBA object.
However, the interaction adaptor needs to be provided with a unit for referring to the naming service function, in order to uniquely identify each CORBA object. Thus, the structure and the workload of the interaction adaptor become large. Moreover, the processing speed decreases by using the naming service function. Accordingly, in the conventional technology, interaction between applications is executed in an inefficient environment.
One approach is to consider a middleware platform itself as a single CORBA object. FIG. 26 is a diagram for describing a conventional middleware platform. The middleware platform realizes interaction between plural applications described in various programming languages. In the middleware platform, CORBA is absorbed and hidden, and a structure storing binary data is used as an interface between the middleware platform and the applications installed in the middleware platform. Accordingly, the middleware platform provides a unique interface, so that the middleware platform itself serves as one CORBA object.
In this case, a broker program for brokering interaction between applications installed in the middleware platform does not require the naming service function for identifying a CORBA object. Thus, the structure and the workload of the broker program can be made smaller, and processing time can be reduced.
Nevertheless, a developer is required to describe the applications installed in the middleware platform according a specification of the unique interface provided by the middleware platform. Thus, the developer needs to have knowledge on the specification of the unique interface provided by the middleware platform, which causes a burden on the developer.
Thus, there is a need for a technology capable of efficiently developing and operating an environment for realizing interaction between plural applications.